Determining control of an internet communication between a sender and a receiver

ABSTRACT

The present invention addresses the possibility of a race condition that arises due to lack of a communication mechanism between the UE and the GGSN, saving unnecessary consumption of radio resources and reducing chances of collisions within the network. Also, the invention prevents the possibility that neither the UE nor GGSN respond appropriately to the Resource Reservation Protocol (RSVP) requirements by halting transmission of any RSVP path/refreshment messages to the IP network in order to refresh/maintain the reservation states due lack of clear assignment of responsibility. This lack of clear understanding between the UE and the GGSN may result in the expiration of the IP network resource reservations made earlier for media streams. This scenario can occur with a higher probability in the absence of this dialog.

[0001] This application claims priority to U.S. Provisional PatentApplication No. 60/293,798, filed on May 25, 2001.

BACKGROUND

[0002] The present invention relates to communications between a userequipment (UE) and a network of a wireless communication system. Morespecifically, the present invention relates to resource reservationprotocol (RSVP) signaling in such a system.

[0003] RSVP signaling is used to make reservations for multimediatraffic originated or terminated in wireless systems. It is used toensure the integrity and Quality of Service (QoS) for these services,especially in communications that are carried across external internetprotocol (IP) networks. RSVP signaling can be originated by the UE andcarried across the radio frequency (RF) interface toward the wirelessnetwork into an IP network, or it can be generated by the general packetradio service gateway support node (GGSN) which acts as RSVP proxyserver on behalf of the UE. In the first case, the UE performance ofRSVP signaling will consume a considerable portion of the air interfaceresources which can be avoided by implementing the Proxy operation inthe GGSN. When the proxy function is performed by the GGSN, anegotiation mechanism is needed between the GGSN and the UE to ensurethe proper operation and avoid any race conditions, where both entitiessimultaneously transmit RSVP signaling. A controlling module should beavailable to assign the RSVP signaling function, if necessary. Thiscontrol module could reside in the GGSN or it can reside in the Policycontrol function (PCF). Lacking a clear assignment of RSVPresponsibility may result in either a race condition, where bothentities transmit simultaneously, or lack of any transmission of RSVPpath and refresh messages to update the reservation state in routersalong the reservation path. This lack of refreshment messages willresult in the expiration of the reservation states and loss of allocatedresources.

SUMMARY

[0004] The present invention addresses the possibility of a racecondition that arises due to lack of a communication mechanism betweenthe UE and the GGSN, saving unnecessary consumption of radio resourcesand reducing chances of collisions within the network. Also, theinvention prevents the possibility that neither the UE nor GGSN respondappropriately to the Resource Reservation Protocol (RSVP) requirementsby halting transmission of any RSVP path/refreshment messages to the IPnetwork in order to refresh/maintain the reservation states due lack ofclear assignment of responsibility. This lack of clear understandingbetween the UE and the GGSN may result in the expiration of the IPnetwork resource reservations made earlier for media streams. Thisscenario can occur with a higher probability in the absence of thisdialog.

BRIEF DESCRIPTION OF THE DRAWING(S)

[0005]FIG. 1 is an example of an RSVP signaling mechanism.

[0006]FIG. 2 is a simplified diagram of a wireless network.

[0007]FIGS. 3 and 4 are flow charts illustrating the GGSN assigning theRSVP proxy function.

[0008]FIGS. 5 and 6 are flow charts illustrating the PCF assigning theRSVP proxy function.

[0009]FIGS. 7 through 14 are flow charts illustrating preferredsignaling scenarios.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

[0010]FIG. 1 shows a system 10 utilizing a RSVP basic operation(illustrated for simplicity in a wired environment). One user (sender12) initiates a multimedia session with a second user (i.e., receiver14) and tries to reserve the resources to establish the session,although other subscribers to the system (S1-S4) are shown. The examplegiven here is limited to subscribers 12, 14 for purposes of simplicity.The RSVP protocol is used to go through the specified route of therequested session and make a reservation to ensure the quality ofservice (QoS) necessary to carry the session. The RSVP Sender 12transmits a PATH message (see path 1, 2, 3, 4 and 5) through a RSVProuter 16, non-RSVP router 18, RSVP tunnel 19, non-RSVP router 20 andRSVP router 22 to allocate the resources along the routing path andstore the media attributes necessary for the session. The Receiver end14 acknowledges the PATH message with a reservation (RESV) message toestablish the resources (see path 6, 7, 8, 9 and 10). The RESV messageis sent through RSVP router 22, non-RSVP router 20, RSVP tunnel 19,non-RSVP router 18 and RSVP router 16. Once the RESV message is receivedat sender 12, a final acknowledgment (not shown) is sent back to thereceiver 14 using the same path. After receipt of the finalacknowledgment, both sides start the session. Periodically, the Senderand the receiver sides will refresh the resource reservation along therouting path through RSVP refresh messages. Otherwise, the reservationstate in routers across the path will expire and resources will bere-allocated.

[0011] For a wireless network, the user equipments 31 or users areconnected to the multimedia/IP network 33 through a wireless network asshown in FIG. 2. FIG. 2 shows the essential parts of a wireless network,such as a universal mobile terrestrial system (UMTS) network 30, thatare involved in the RSVP operations. As shown, the Call Server ControlFunction (CSCF) policy control function (PCF) 32 acts as the policycontrol point where decisions are made regarding the user services, thehandling of media streams and QoS resource issues. The GGSN 34represents the gateway function, which potentially acts as the RSVPSend/Receive proxy. Also, the GGSN 34 contains all the mobile profileinformation packet data protocol (PDP) context, and has the resourcesnecessary to carry both signaling and traffic information. The GGSN 34acts as the controlling authority for all mobile activities. It assignsthe IP address and decides, with the serving GPRS support node (SGSN)36, the potential modes of operation. The RSVP signaling is transparentto both the UMTS terrestrial radio access network (UTRAN) 38 and SGSN36. The decision point and the associated control logic on the mannerand location of handing the RSVP signaling is preferably located ateither the CSCF (PCF) 34 in association with the overall QoS policycontrol or at the GGSN 34 with other resource control functions. In analternative embodiment, a dynamic allocation of responsibility of theRSVP signaling to the CSCF (PCF) 34 and CGSN 34 is provided since theGGSN 34 is in control of most of the network resources and can detect(or determine) a situation where the wireless network is congested anduse this mechanism to alleviate some of the excess traffic.

[0012] In one embodiment, the GGSN 34 decides whether it or the UE 31will perform the RSVP function. To prevent a race condition, multiple orno transmissions, the GGSN 34 interacts with the UE and clearly assignsthe responsibilities for RSVP signaling. The decision may be madestatically or dynamically. If the decision is made statically, thedecision is made only at the time of initiation. If the decision is madedynamically, the GGSN 34 may change who performs the RSVP function atany time. This decision is typically based on local traffic conditions,such as the availability of air link resources versus the availabilityof network resources, and local policy. To illustrate, if air linkresources are scarce, the GGSN 34 may decide to switch the RSVP functionfrom some UEs to itself. By contrast, if the GGSN's resources are beinghighly utilized, it may shift the RSVP function to some of the UEs.

[0013] A flow chart indicating a preferred procedure for the GGSN 34 toassign the RSVP function to the UE 31 is illustrated in FIG. 3. Afterthe GGSN 34 determines that the UE 31 will perform the RSVP function, itsends the UE 31 a message indicating that the UE 31 controls the RSVPfunction via the wireless network, step A1. After the UE 31 receivesthat message, it sends an acknowledgment message (ACK) to the GGSN 34,step A2. To reserve a path to the destination user, the UE 31 sends areservation path message (PATH message) to the external network 33through the wireless network 30, step A3. After the external network 33receives the PATH message, it reserves those resources for the UE 31 andsends the UE 31 back through the wireless network 30 a RSVP reservationmessage, step A4. After the UE 31 receives the RSVP reservation message,it sends an activate/modified secondary PDP context message to the SGSN36 via the UTRAN 38, step A5. After receiving that message, the SGSN 36sends a context request message through the GGSN 34, step A6. Inresponse to receiving the context request message, the GGSN 34 sends aRSVP reservation (RESV) confirmation message to the external network 33and a context response message to the SGSN 36, step A7. After the SGSNreceives the context response message, it sends an activate/modifysecondary PDP context accept message to the UE 31, step A8. After the UEreceives the acceptance message, it carries on the proxy function, stepA9.

[0014] To maintain the path throughout the external network 33, the UE31 must periodically send a refresh path message through the externalnetwork 33. The refreshing prevents components of the external network33 from timing out and releasing the resources. After the externalnetwork 33 receives the refresh path message, it maintains itsreservation of the path and sends the UE 31 a refresh reservationmessage indicating that the path will be maintained.

[0015] In an alternate embodiment, although the GGSN 34 makes the proxyfunction assignment, the UE 31 may accept or reject the assignment. Thisprocedure allows for negotiation between the UE 31 and GGSN 34. Afterreceiving the message from the GGSN 34 indicating that the UE 31 shouldperform the RSVP function, the UE 31 responds by accepting or rejecting,such as by an acknowledgment (ACK) or negative acknowledgment (NAK). Ifthe UE 31 rejects the assignment, the UE 31 does not originate any RSVPmessages and the GGSN 34 performs the function.

[0016] A flow chart indicating a preferred procedure for the GGSN 34 toassign the RSVP function to itself is illustrated in FIG. 4. After theGGSN 34 determines that it will perform the proxy function, it sends theUE 31 a message indicating that the GGSN 34 will control the RSVPfunction via the wireless network 30, step B1. After the UE 31 receivesthat message, it sends an acknowledgment message to the GGSN 34, stepB2. To reserve a path through the external network 33, the GGSN 34 sendsa PATH message to the external network 33, step B3. After the externalnetwork 33 receives the PATH message, it reserves path resources andsends the GGSN 34 back through the wireless network 30 a RSVPreservation message, step B4. After the GGSN 34 receives the RSVPreservation message, it sends a RSVP reservation confirmation message tothe external network 33. At the same time, it sends a modified secondaryPDP context message to the SGSN 36, step B5. After the SGSN 36 receivesthat message, it sends a create/modify secondary PDP context message tothe UE 31 via the UTRAN 38, step B6. In response to receiving themessage, the UE 31 sends an activate/modify secondary PDP contextmessage to the SGSN 36 and GGSN 34, steps B7 and BS. After receivingthat message, the GGSN 34 sends an activate/modify secondary PDP contextaccept message to the UE 31 and carries on the RSVP function, steps B9and B10. To maintain the path through the external network, the GGSN 34periodically sends a refresh path message through the external network33.

[0017] In another embodiment, the PCF 32 decides whether the GGSN 34 orthe UE 31 will perform the RSVP function. This decision may also be madestatically or dynamically. If the decision is made statically, thedecision is made at the time of initiation. If the decision is madedynamically, the PCF 32 may change who performs the RSVP function at anytime. Alternately, the PCF 32 may delegate the decision to the GGSN 34.After the PCF 32 sends a delegation message to the GGSN 34, the GGSN 34decides who performs the RSVP function.

[0018] A flow chart indicating a preferred procedure for the PCF 32 toassign the RSVP function to the UE 31 is illustrated in FIG. 5. Afterthe PCF 32 determines that the UE 31 will perform the RSVP function, itsends the GGSN 34 a message indicating that the UE 31 controls the RSVPfunction, step C1. The GGSN 34 forwards the message to the UE 31 via thewireless network 33, step C2, and optionally acknowledges receipt of themessage by sending an acknowledgment (ACK) to the PCF 32, step C3. Afterthe UE 31 receives the forwarded message, it also sends an ACK to thePCF 32, step C4. Alternately, the GGSN 34 does not send an ACK. The PCF32 treats the ACK from the UE 31 as acknowledging receipt from both theUE 31 and GGSN 34.

[0019] The UE 31 also sends a PATH message to the external network 33,step C6. After the external network 33 receives the PATH message, itreserves those resources for the UE 31 and sends the UE 31 back throughthe wireless network 30 an RSVP reservation message, step C6. After theUE 31 receives the RSVP reservation message, it sends an activate/modifysecondary PDP context message to the SGSN 36 via the UTRAN 38, step C7.In response to receiving that message, the SGSN 36 sends a contextrequest message to the GGSN 34, step C8. Subsequently, the GGSN 34 sendsan RSVP space reservation confirmation message to the external network33 and a context response message to the SGSN 36, step C9. After theSGSN 36 receives a context response message, it sends an activate/modifysecondary PDP context accept message to the UE 31 via the UTRAN 38, stepC10. At that point, the UE 31 carries on the RSVP function, step C11.Periodically, the UE 31 sends refresh messages to the external network33 to maintain the path through the external network 33.

[0020] A flow chart indicating a preferred procedure for the PCF 32 toassign the RSVP function to the GGSN 34 is illustrated in FIG. 6. Afterthe PCF 32 determines that the GGSN 34 will perform the RSVP function,it sends the GGSN 34 a message indicating that the GGSN 34 controls theRSVP function, step D1. After the GGSN 34 receives that message, itsends a message via the SGSN 36 and the UTRAN 38 to the UE 31 indicatingthat the UE 31 should not perform the RSVP function, step D2.Optionally, the GGSN 34 also acknowledges receipt of the control messageby sending an ACK to the PCF 32, step D3. After the UE 31 receives themessage, it also sends an ACK to the PCF 32, step D4. Alternately, theGGSN 34 does not send an ACK. The PCF 32 treats the ACK from the UE 31as acknowledging receipt from both the UE 31 and GGSN 34.

[0021] To reserve a path through the external network 33, the GGSN 34sends a PATH message to the external network 33, step D5. After theexternal network receives the PATH message, it reserves PATH resourcesand sends the GGSN 34 an RSVP reservation message, step D6. In responseto the GGSN 34 receiving the RSVP message, it sends an RSVP reservationconfirmation message to the external network 33. Simultaneously, itsends a modified secondary PDP context message to the SGSN 36, step D7.After receiving that message, the SGSN 36 sends a create/modifysecondary PDP context message to the UE 31 via the UTRAN 38, step D8.After receiving that message, the UE 31 sends an activate/modifysecondary PDP context message to the GGSN 34, step D9. In response toreceiving that message, the GGSN 34 sends an activate/modify secondaryPDP context accept message to the UE 31 and the GGSN 34 carries on theRSVP function, steps D10 and D11. To maintain the path throughout theexternal network, the GGSN 34 periodically sends a refresh path messagethrough the external network 33.

[0022] In another embodiment, the UE 31 and GGSN 34 negotiateresponsibility for the RSVP signaling, for how long, and under whatcircumstances the responsibilities can shift. Either the UE 31 or GGSN34 may initiate the negotiations.

[0023] In another embodiment, the PCF 32 is used in conjunction with theUE policy enforcement so that the PCF 32 assigns the responsibilities toeither the UE 31 or the GGSN 34. The PCF in this case sends two orders:one to the GGSN 34 and the second to the UE 31. This prevents a racecondition or no transmission from occurring. The wireless network mayalso be hard coded to only allow either the GGSN 34 or UE 31 to performthe proxy function. The decision is communicated to the UE 31 during thePDP context activation process.

[0024] FIGS. 7-14 illustrate some preferred signaling procedures betweenthe UE 31, UTRAN 38, SGSN 36, GGSN 34, PCF 32 and external network 33for differing signaling scenarios.

[0025]FIG. 7 illustrates one preferred signaling arrangement for PCFcontrol of RSVP signaling. In FIGS. 7 and 8, the PCF 32 assigns controlto the GGSN 34. The steps start at the top line of the figure andsubsequent steps in time are represented at succeedingly lower positionsbeneath the top line. The direction of signaling is depicted by anarrow.

[0026] Initially, the proxy call service control function (PCSCF)/PCF 32signals the GGSN 34 to act as the RSVP SEND/RECEIVE proxy, step E1. TheGGSN 34 acknowledges, sending an ACK to the PCF 32, step E2. The PCF 32,step E3, communicates to the GGSN 34 that the UE 31 shall not use RSVPsignaling. The GGSN 34, step E4, communicates this message to the SGSN36. The SGSN 36, step E5, communicates this message to the UE 31. The UE31 acknowledges this responsibility and, step E6, communicates an ACK tothe SGSN 36. The SGSN 36, step E7, communicates the ACK to the GGSN 34.The GGSN 34, step E8, communicates the ACK to the PCF 32.

[0027] In FIG. 8, the PCF 32, at step F1, communicates to the GGSN 34that the GGSN 34 shall act as the RSVP SEND/RECEIVE proxy and the UE 31should be silent. The GGSN 34 initiates an RSVP SEND/RECEIVE proxy forthe UE 31 and informs the UE 31 to be silent, step F2. This iscommunicated to the SGSN 36, step F3, which, step F4, communicates it tothe UE 31.

[0028] The UE 31, at step F5, sends an acknowledgment to the SGSN 36.The SGSN 36, step F6, communicates the acknowledgment to the GGSN 34which, in turn, transmits the acknowledgment, step F7, to the PCF 32.The UE 31 does not send any RSVP messages until further notice.

[0029]FIGS. 9 and 10 illustrate various signaling scenarios for the GGSN34 deciding the responsibility for the RSVP proxy function. In FIG. 9,the GGSN 34 decides it will assume the RSVP proxy function. The UE 31,at step G1, transmits an RSVP PATH to the GGSN 34. The GGSN, step G2,initiates a path through the External Network 33 using a RSVP PATHmessage. The GGSN 34, step G3, upon receipt of the RSVP PATH from the UE31, initializes the PROXY operation and informs the UE 31 to stop usinga STOP RSVP message, step G4. The UE 31 sends an acknowledgment to theGGSN 34 through the UTRAN 38 and SGSN 36, step G5. The UE 31 does notinitiate any RSVP messages until further notice from GGSN 34. After theGGSN 34 receives a RSVP RESV message from the external network 33, theGGSN 34 sends a Modify Secondary PDP Context message to the SGSN, stepG7. The SGSN 36 sends that message to the UE 31, step G8. After the UE31 receives the Modify Secondary PDP Context message, it sends anActivate/Modify Secondary PDP message to the SGSN 36, step G9. The SGSN36 forwards that message to the GGSN 34, step G10. To maintain the paththrough the external network, the GGSN 34, periodically transmits aRefresh PATH message, step G11, and receives a Refresh RESV message,step G12.

[0030] In FIG. 10, the GGSN 34 decides to support the RSVP proxyfunction, after negotiation with the UE 31. The UE 31, step H1,transmits a message to the GGSN 34 indicating that it should act asproxy for RSVP signaling. The GGSN 34, which decides to support theProxy operation, step H2, initializes the PROXY operation and informsthe UE 31 to stop transmission, step H3. This decision is incorporatedin an acknowledgment to the UE 31. The UE 31 accepts the GGSN order andstops sending RSVP messages.

[0031] The UE 31 initiates the session and, step H4, creates a secondaryPDP context message which is transmitted to the GGSN 34 via the UTRAN 38and SGSN 36, steps H5 and H6. The GGSN 34, step H7, modifies thesecondary PDP context message and accepts the UE's communication andtransmits the acceptance to the UE 31, through the same path, steps H8and H9. The GGSN 34, step H10, transmits an RSVP PATH message to theexternal network 33 and receives a RSVP RESV in reply, step H11. TheGGSN 34, step H12, confirms receipt of the RSVP RESV by sending a RSVPRESV confirmation. To maintain the path, the GGSN 34 periodically sendsa Refresh PATH message, step H13, and, in turn, receives a Refresh RESVmessage, step H14.

[0032] The UE 31 and GGSN 34 may engage in a negotiation as to who shalltake the responsibility for RSVP signaling, for how long and under whatcircumstances the responsibilities can shift. In FIG. 11, the UE 31, atstep I1, requests that the GGSN 34 acts as proxy for RSVP Signaling. TheGGSN 34, step I2, decides that it will not support the PROXY operationand, step I3, informs the UE 31 to resume responsibility by transmittinga NAK. The UE 31, step I4, transmits an RSVP PATH message to the GGSN34. The RSVP PATH message is transmitted to the receiving UE, step I5,through the External Network 33. The receiving UE transmits an RSVP RESVthrough the External Network 33 to the GGSN 34, step I6. In turn, theGGSN 34 transmits the RSVP RESV to the UE 31, step I7 and a RSVP RESVconfirmation message to the external network, step 110. The UE 31, stepI8, transmits an Activate/Modify secondary PDP Context to the SGSN 36.The SGSN 36, step I9 transmits a Context request to the GGSN 34. At stepI11, the GGSN 34 transmits a Context Response to the SGSN 36 which sendsan Activate/Modify Secondary PDP Context Accept message, step I12, tothe UE 31. The UE 31, to maintain the path, transmits, step I13, arefresh message, which is communicated to the GGSN 34. This refresh pathmessage is transmitted by the GGSN 34, step I14, to the External Network33. The External Network 33, responds to the GGSN 34 with a RefreshRSVP, step I15. The GGSN 34, step I16, transmits this message to the UE31.

[0033] The GGSN 34 may also send messages to the UE 31 indicating thatthe GGSN 34 recommends that either the UE 31 or GGSN 34 perform the RSVPfunction. The UE 31 may either accept or decline the recommendation.Typically, the final determination of who performs the RSVP function, ifnegotiation is unsuccessful, is left to the GGSN 34.

[0034] In FIG. 12, the GGSN 34 decides to support the proxy operation.The External Network 33, step J1, transmits an RSVP PATH message to theGGSN 34 from a UE in the External Network 33. The GGSN 34, step J2,decides to support the proxy operation and informs the UE 31 not to sendRSVP signaling. The GGSN 34, step J3 transmits a Create/Modify PDPContext to the SGSN 36 which, step J4, transmits this message to the UE31. The UE 31 receives this message and, step J5, transmits anActivate/Modify Secondary PDP Context to the SGSN 36. The SGSN 36, stepJ6, transmits this message to the GGSN 34.

[0035] The GGSN 34, step J7, transmits an Activate/Modify Secondary PDPContext Accept to the SGSN 36, which, step J8, transmits this message tothe UE 31. In addition, the GGSN 34, step J9, transmits an RSVP RESV tothe External Network 33 which responds with an RSVP RESV Confirmation,step J10. The UE associated with the External Network 33, step J11,transmits, through the External Network 33 to the GGSN 34, a RefreshPath Request message. The GGSN 34 responds by sending a Refresh RESVmessage, step J12.

[0036] In FIG. 13, the PCF 32 makes the RSVP function decisions. The UE31, step K1, sends a request that the GGSN 34 should act as RSVP PROXYto the PCF 32. This message is handled by the PCF 32 which, step K2makes a decision and, step K3 advises the GGSN 34 that it is assignedthe responsibility for the RSVP proxy. The PCF 32, step K4, furtheradvises the UE 31 that it should stop sending RSVP messages. The GGSN34, step K5, acknowledges its assignment to the PCF 32 and the UE 31,step K6, also acknowledges that it will stop sending RSVP messages.

[0037]FIG. 14 is an arrangement similar to FIG. 13 except that the GGSN34 sends a request to the PCF 32 that the UE 31 should act as the RSVPproxy, step L1. The PCF 32, step L2, makes a decision and assigns theRSVP proxy assignment to the UE 31, step L3. The PCF 32 furtherinstructs the GGSN 34 that it not act as RSVP proxy, step L4. The UE 31acknowledges its assignment, step L5, and the GGSN 34 acknowledges itsassignment, step L6.

[0038] It should be understood that the PCF can make the reversedecisions to those shown in FIGS. 13 and 14. For example, consideringFIG. 13, when the UE 31 requests that the GGSN 34 should act as RSVP,the PCF 32 may decide that the UE 31 should act as RSVP proxy anyway. Ina similar fashion, making to reference to FIG. 14, the PCF 32 inresponse to a request from the GGSN 34, that the UE 31 should act asRSVP PROXY, may decide that the GGSN 34 act as the RSVP proxy anyway.Since, in FIGS. 13 and 14, the PCF 32 sends an order to both the UE 31and GGSN 34, it is unlikely that a race condition or no transmission atall will occur.

[0039] To assure that no RSVP signaling occurs during static set up(initialization), a control mechanism is preferably used that instructsthe UE 31 not to send RSVP signaling messages while allocating theresponsibility to the GGSN 34 or alternatively, the control mechanisminstructs the GGSN 34 not to send RSVP signaling messages whileallocating the responsibility to the UE 31.

What is claimed is:
 1. A method for assigning responsibility forresource reservation protocol (RSVP) signaling in order to supportmultimedia communications between a user equipment (UE) in a wirelesscommunication network and a user of an external network, the wirelessnetwork having both the UE and a general packet radio service gatewaysupport node (GGSN) capable of supporting RSVP signaling, the methodcomprising: providing a policy control function (PCF) capable ofassigning RSVP signaling to either the GGSN or UE; the PCF assigningRSVP signaling to the GGSN or UE; if the PCF assigns RSVP signaling tothe GGSN: the PCF signaling the GGSN assignment to the GGSN; the PCFsignaling the UE not to perform RSVP signaling; and in response toreceiving the GGSN assignment, the GGSN performing RSVP signaling; andif the PCF assigns RSVP signaling to the UE: the PCF signaling the UEassignment to the GGSN; the PCF signaling the GGSN not to perform RSVPsignaling; and in response to receiving the UE assignment, the UEperforming RSVP signaling.
 2. The method of claim 1 wherein the PCFdelegates the RSVP signaling assignment to the GGSN.
 3. The method ofclaim 2 wherein the GGSN bases the delegated RSVP signaling assignmentin response to local traffic conditions.
 4. The method of claim 2wherein the GGSN bases the delegated RSVP signaling assignment to alocal policy of the GGSN.
 5. A method for assigning responsibility forresource reservation protocol (RSVP) signaling in order to supportmultimedia communications between a user equipment (UE) in a wirelesscommunication network and a user of an external network, the wirelessnetwork having both the UE and a general packet radio service gatewaysupport node (GGSN) capable of supporting RSVP signaling, the methodcomprising: providing the GGSN capable of assigning RSVP signaling toeither the GGSN or UE; the GGSN assigning RSVP signaling to the GGSN orUE; if the GGSN assigns RSVP signaling to the GGSN: the GGSN signalingto the UE not to perform RSVP signaling; and the GGSN performing theRSVP signaling; and if the GGSN assigns RSVP signaling to the UE: theGGSN signaling the UE assignment to the UE; in response to receiving theUE assignment, the UE performing RSVP signaling.
 6. The method of claim5 wherein the GGSN bases the RSVP signaling assignment in response tolocal traffic conditions.
 7. The method of claim 5 wherein the GGSNbases the RSVP signaling assignment in response to a local policy of theGGSN.
 8. The method of claim 5 wherein the GGSN bases the RSVP signalingassignment on a negotiation between the GGSN and UE.
 9. The method ofclaim 5 wherein in response to the GGSN receiving a message indicatingthe GGSN should perform RSVP signaling from the UE, the GGSN makes theRSVP signaling assignment.
 10. The method of claim 5 wherein if the GGSNassumes the RSVP signaling an acknowledgment is sent to the UE and ifthe GGSN assigns the RSVP signaling to the UE a negative acknowledgmentis sent to the UE.
 11. A method for assigning responsibility forresource reservation protocol (RSVP) signaling in order to supportmultimedia communications between a user equipment (UE) in a wirelesscommunication network and a user of an external network, the wirelessnetwork having both the UE and a general packet radio service gatewaysupport node (GGSN) capable of supporting RSVP signaling, the methodcomprising: sending a first message from one to another of the UE orGGSN indicating whether the UE or GGSN should perform the RSVPsignaling; and in response to receiving the first message, the other ofthe UE or GGSN sending a second message indicating an acceptance ordeclining the indicated performer.
 12. The method of claim 11 whereinthe GGSN is the one and the UE is the other, the method furthercomprising if the GGSN receiving the second message indicatingdeclining, the GGSN deciding who performs RSVP signaling.
 13. The methodof claim 11 wherein the GGSN is the one and the UE is the other and thefirst message indicating the GGSN assuming RSVP signaling, the methodfurther comprising if the GGSN receiving the second message indicatingan acceptance, the GGSN performing RSVP signaling.
 14. The method ofclaim 11 wherein the UE is the one and the GGSN is the other, the methodfurther comprising in response to receiving the first message the GGSNdetermining who performs the RSVP signaling.
 15. The method of claim 14wherein the GGSN determining the RSVP signaling performing based on thelocal traffic conditions.
 16. The method of claim 14 wherein the GGSNdetermining the RSVP signaling performing based on a local policy of theGGSN.